During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user calls Config.Clone and mutates the returned Config, or uses Config.GetConfigForClient. This can cause a client to resume a session with a server that it would not have resumed with during the initial handshake, or cause a server to resume a session with a client that it would not have resumed with during the initial handshake.

If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service.

This only affects TLS 1.3.

Validating certificate chains which use policies is unexpectedly inefficient when certificates in the chain contain a very large number of policy mappings, possibly causing denial of service.

This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.

During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls.

url.Parse insufficiently validated the host/authority component and accepted some invalid URLs.

Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out. Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime. Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.

The net/url package does not set a limit on the number of query parameters in a query.

While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

The ParseAddress function constructs domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.

The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.

This affects programs which parse untrusted PEM inputs.

Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.

This affects programs which validate arbitrary certificate chains.

Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.

This affects programs which validate arbitrary certificate chains.

archive/zip uses a super-linear file name indexing algorithm that is invoked the first time a file in an archive is opened. This can lead to a denial of service when consuming a maliciously constructed ZIP archive.

An excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard SANs in the leaf certificate. For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com.

If the PATH environment variable contains paths which are executables (rather than just directories), passing certain strings to LookPath ("", ".", and ".."), can result in the binaries listed in the PATH being unexpectedly returned.

On Linux, if the target of Root.Chmod is replaced with a symlink while the chmod operation is in progress, Chmod can operate on the target of the symlink, even when the target lies outside the root.

The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag, which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its target before acting and returns an error if the target is a symlink lying outside the root, so the impact is limited to cases where the target is replaced with a symlink between the check and operation.

Context was not properly tracked across template branches for JS template literals, leading to possibly incorrect escaping of content when branches were used. Additionally template actions within JS template literals did not properly track the brace depth, leading to incorrect escaping being applied.

These issues could cause actions within JS template literals to be incorrectly or improperly escaped, leading to XSS vulnerabilities.

Actions which insert URLs into the content attribute of HTML meta tags are not escaped. This can allow XSS if the meta tag also has an http-equiv attribute with the value "refresh".

A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be used to disable escaping URLs in actions in the meta content attribute which follow "url=" by setting htmlmetacontenturlescape=0.

tar.Reader can allocate an unbounded amount of memory when reading a maliciously-crafted archive containing a large number of sparse regions encoded in the "old GNU sparse map" format.

During the TLS 1.3 handshake if multiple messages are sent in records that span encryption level boundaries (for instance the Client Hello and Encrypted Extensions messages), the subsequent messages may be processed before the encryption level changes. This can cause some minor information disclosure if a network-local attacker can inject messages during the handshake.

The Reader.ReadResponse function constructs a response string through repeated string concatenation of lines. When the number of lines in a response is large, this can cause excessive CPU consumption.

When Conn.Handshake fails during ALPN negotiation the error contains attacker controlled information (the ALPN protocols sent by the client) which is not escaped.

Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does not have a limit. By sending a lot of very small cookies such as "a=;", an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.

Parsing a maliciously crafted DER payload could allocate large amounts of memory, causing memory exhaustion.

The Parse function permits values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.

tar.Reader does not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions can cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input can result in large allocations.

On Unix platforms, when listing the contents of a directory using File.ReadDir or File.Readdir the returned FileInfo could reference a file outside of the Root in which the File was opened.

The impact of this escape is limited to reading metadata provided by lstat from arbitrary locations on the filesystem without permitting reading or writing files outside the root.

A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low. This advisory outlines the issue, identifies the affected versions, and provides remediation steps for impacted users.

Impact

Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.

A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.

Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.

Vulnerability details

• AuthZ bypass and privilege escalation: An attacker could exploit a bypass using an API request with Content-Length set to 0, causing the Docker daemon to forward the request without the body to the AuthZ plugin, which might approve the request incorrectly.
• Initial fix: The issue was fixed in Docker Engine v18.09.1 January 2019..
• Regression: The fix was not included in Docker Engine v19.03 or newer versions. This was identified in April 2024 and patches were released for the affected versions on July 23, 2024. The issue was assigned CVE-2024-41110.

Patches

• docker-ce v27.1.1 containes patches to fix the vulnerability.
• Patches have also been merged into the master, 19.0, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches.

Remediation steps

• If you are running an affected version, update to the most recent patched version.
• Mitigation if unable to update immediately:
  • Avoid using AuthZ plugins.
  • Restrict access to the Docker API to trusted parties, following the principle of least privilege.

References

• moby/moby@fc274cd
• moby/moby@a79fabb
• https://www.docker.com/blog/docker-security-advisory-docker-engine-authz-plugin/

Summary

A security vulnerability has been detected that allows attackers to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.

This is an incomplete fix for CVE-2024-41110.

Impact

If you don't use AuthZ plugins, you are not affected.

Using a specially-crafted API request, an attacker could make the Docker daemon forward the request to an authorization plugin without the body. The authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.

Anyone who depends on authorization plugins that introspect the request body to make access control decisions is potentially impacted.

Workarounds

If unable to update immediately:

• Avoid using AuthZ plugins that rely on request body inspection for security decisions.
• Restrict access to the Docker API to trusted parties, following the principle of least privilege.

Credits

• 1seal / Oleh Konko (@1seal)
• Cody (c@wormhole.guru)
• Asim Viladi Oglu Manizada (@manizada)

Resources

• CVE-2024-41110 / GHSA-v23v-6jw2-98fq

Summary

A security vulnerability has been detected that allows plugins privilege validation to be bypassed during docker plugin install. Due to an error in the daemon's privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user.

Plugins that request exactly one privilege are also affected, because no comparison is performed at all.

Impact

If plugins are not in use, there is no impact.

When a plugin is installed, the daemon computes the privileges required by the plugin's configuration and compares them with the privileges approved during installation. A malicious plugin can exploit this bug so that the daemon accepts privileges that differ from what was intended to be approved.

Anyone who depends on the plugin installation approval flow as a meaningful security boundary is potentially impacted.

Depending on the privilege set involved, this may include highly sensitive plugin permissions such as broad device access.

For consideration: exploitation still requires a plugin to be installed from a malicious source, and Docker plugins are relatively uncommon. Docker Desktop also does not support plugins.

Workarounds

If unable to update immediately:

• Do not install plugins from untrusted sources
• Carefully review all privileges requested during docker plugin install
• Restrict access to the Docker daemon to trusted parties, following the principle of least privilege
• Avoid relying on plugin privilege approval as the only control boundary for sensitive environments

Credits

• Reported by Cody (c@wormhole.guru, PGP 0x9FA5B73E)

Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker, or Docker Engine.

Firewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.

Impact

The iptables rules created by Docker are removed when firewalld is reloaded using, for example "firewall-cmd --reload", "killall -HUP firewalld", or "systemctl reload firewalld".

When that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.

Once these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.

Containers running in networks created with --internal or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.

Where Docker Engine is not running in the host's network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.

Patches

Moby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.

Workarounds

After reloading firewalld, either:

• Restart the docker daemon,
• Re-create bridge networks, or
• Use rootless mode.

References

https://firewalld.org/
https://firewalld.org/documentation/howto/reload-firewalld.html

Impact

What kind of vulnerability is it? Who is impacted?

It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.

The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.

Who is impacted?
This affects gRPC-Go servers that meet both of the following criteria:

1. They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx).
2. Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).

The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.

Patches

Has the problem been patched? What versions should users upgrade to?

Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.

Users should upgrade to the following versions (or newer):

• v1.79.3
• The latest master branch.

It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:

1. Use a Validating Interceptor (Recommended Mitigation)

Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:

func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
    if info.FullMethod == "" || info.FullMethod[0] != '/' {
        return nil, status.Errorf(codes.Unimplemented, "malformed method name")
    }   
    return handler(ctx, req)
}

// Ensure this is the FIRST interceptor in your chain
s := grpc.NewServer(
    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)

2. Infrastructure-Level Normalization

If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.

3. Policy Hardening

Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

Summary

The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.

Root Cause

sdk/resource/host_id.go line 42:

if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil {

Compare with the fixed Darwin path at line 58:

result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice")

The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator.

Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.

The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.

Attack

1. Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk
2. Attacker places a malicious kenv binary earlier in $PATH
3. Application initializes OpenTelemetry resource detection at startup
4. hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary
5. Arbitrary code executes in the context of the application

Same attack vector and impact as CVE-2026-24051.

Suggested Fix

Use the absolute path:

if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil {

On FreeBSD, kenv is located at /bin/kenv.

Impact

The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application.

Patches

This has been patched in d45961b, which was released with v1.40.0.

References

• CWE-426: Untrusted Search Path

Impact

An overly broad default permission vulnerability was found in containerd.

• /var/lib/containerd was created with the permission bits 0o711, while it should be created with 0o700
  • Allowed local users on the host to potentially access the metadata store and the content store
• /run/containerd/io.containerd.grpc.v1.cri was created with 0o755, while it should be created with 0o700
  • Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
• /run/containerd/io.containerd.sandbox.controller.v1.shim was created with 0o711, while it should be created with 0o700

The directory paths may differ depending on the daemon configuration.
When the temp directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.

Patches

This bug has been fixed in the following containerd versions:

• 2.2.0
• 2.1.5
• 2.0.7
• 1.7.29

Users should update to these versions to resolve the issue.
These updates automatically change the permissions of the existing directories.

[!NOTE]

/run/containerd and /run/containerd/io.containerd.runtime.v2.task are still created with 0o711.
This is an expected behavior for supporting userns-remapped containers.

Workarounds

The system administrator on the host can manually chmod the directories to not
have group or world accessible permisisons:

chmod 700 /var/lib/containerd
chmod 700 /run/containerd/io.containerd.grpc.v1.cri
chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim

An alternative mitigation would be to run containerd in rootless mode.

Credits

The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the containerd security policy.

For more information

If you have any questions or comments about this advisory:

• Open an issue in containerd
• Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

• Report a new vulnerability

Impact

A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks.

Repetitive calls of CRI Attach (e.g., kubectl attach) could increase the memory usage of containerd.

Patches

This bug has been fixed in the following containerd versions:

• 2.2.0
• 2.1.5
• 2.0.7
• 1.7.29

Users should update to these versions to resolve the issue.

Workarounds

Set up an admission controller to control accesses to pods/attach resources.
e.g., Validating Admission Policy.

Credits

The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the containerd security policy.

References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329

For more information

If you have any questions or comments about this advisory:

• Open an issue in containerd
• Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

• Report a new vulnerability

Impact

A bug was found in containerd where containers launched with a User set as a UID:GID larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user.

Patches

This bug has been fixed in the following containerd versions:

• 2.0.4 (Fixed in containerd/containerd@1a43cb6)
• 1.7.27 (Fixed in containerd/containerd@05044ec)
• 1.6.38 (Fixed in containerd/containerd@cf158e8)

Users should update to these versions to resolve the issue.

Workarounds

Ensure that only trusted images are used and that only trusted users have permissions to import images.

Credits

The containerd project would like to thank Benjamin Koltermann and emxll for responsibly disclosing this issue in accordance with the containerd security policy.

References

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-40635

For more information

If you have any questions or comments about this advisory:

• Open an issue in containerd
• Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

• Report a new vulnerability
• Email us at [security@containerd.io](mailto:security@containerd.io)

/sys/devices/virtual/powercap accessible by default to containers

Intel's RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via sysfs. As RAPL is an interface to access a hardware feature, it is only available when running on bare metal with the module compiled into the kernel.

By 2019, it was realized that in some cases unprivileged access to RAPL readings could be exploited as a power-based side-channel against security features including AES-NI (potentially inside a SGX enclave) and KASLR (kernel address space layout randomization). Also known as the PLATYPUS attack, Intel assigned CVE-2020-8694 and CVE-2020-8695, and AMD assigned CVE-2020-12912.

Several mitigations were applied; Intel reduced the sampling resolution via a microcode update, and the Linux kernel prevents access by non-root users since 5.10. However, this kernel-based mitigation does not apply to many container-based scenarios:

• Unless using user namespaces, root inside a container has the same level of privilege as root outside the container, but with a slightly more narrow view of the system
• sysfs is mounted inside containers read-only; however only read access is needed to carry out this attack on an unpatched CPU

While this is not a direct vulnerability in container runtimes, defense in depth and safe defaults are valuable and preferred, especially as this poses a risk to multi-tenant container environments. This is provided by masking /sys/devices/virtual/powercap in the default mount configuration, and adding an additional set of rules to deny it in the default AppArmor profile.

While sysfs is not the only way to read from the RAPL subsystem, other ways of accessing it require additional capabilities such as CAP_SYS_RAWIO which is not available to containers by default, or perf paranoia level less than 1, which is a non-default kernel tunable.

References

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912
• https://platypusattack.com/
• https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71
• https://web.eece.maine.edu/~vweaver/projects/rapl/

This issue affects Docker CLI through 29.1.5

Impact

Docker CLI for Windows searches for plugin binaries in C:\ProgramData\Docker\cli-plugins, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the docker CLI is executed as a privileged user.

This issue affects Docker CLI through v29.1.5 (fixed in v29.2.0). It impacts Windows binaries acting as a CLI plugin manager via the [github.com/docker/cli/cli-plugins/manager](https://pkg.go.dev/github.com/docker/cli@v29.1.5+incompatible/cli-plugins/manager) package, which is consumed by downstream projects such as Docker Compose.

Docker Compose became affected starting in v2.31.0, when it incorporated the relevant CLI plugin manager code (see docker/compose#12300), and is fixed in v5.1.0.

This issue does not impact non-Windows binaries or projects that do not use the plugin manager code.

Patches

Fixed version starts with 29.2.0

This issue was fixed in docker/cli@1375933 (docker/cli#6713), which removed %PROGRAMDATA%\Docker\cli-plugins from the list of paths used for plugin-discovery on Windows.

Workarounds

None

Resources

• Pull request: "cli-plugins/manager: remove legacy system-wide cli-plugin path" (cli-plugins/manager: remove legacy system-wide cli-plugin path docker/cli#6713)
• Patch: https://github.com/docker/cli/commit/13759330b1f7e7cb0d67047ea42c5482548ba7fa.patch

Credits

Nitesh Surana (niteshsurana.com) of Trend Research of TrendAI

Summary

Use of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields.

Details

OpenBao (and presumably HashiCorp Vault) have surfaced error messages from mapstructure as follows:

https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L43-L50

			_, _, err := d.getPrimitive(field, schema)
			if err != nil {
				return fmt.Errorf("error converting input for field %q: %w", field, err)
			}

where this calls mapstructure.WeakDecode(...): https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L181-L193

func (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) {
	raw, ok := d.Raw[k]
	if !ok {
		return nil, false, nil
	}

	switch t := schema.Type; t {
	case TypeBool:
		var result bool
		if err := mapstructure.WeakDecode(raw, &result); err != nil {
			return nil, false, err
		}
		return result, true, nil

Notably, WeakDecode(...) eventually calls one of the decode helpers, which surfaces the original value:

https://github.com/go-viper/mapstructure/blob/1a66224d5e54d8757f63bd66339cf764c3292c21/mapstructure.go#L679-L686

https://github.com/go-viper/mapstructure/blob/1a66224d5e54d8757f63bd66339cf764c3292c21/mapstructure.go#L726-L730

https://github.com/go-viper/mapstructure/blob/1a66224d5e54d8757f63bd66339cf764c3292c21/mapstructure.go#L783-L787

& more.

PoC

To reproduce with OpenBao:

$ podman run -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300

and in a new tab:

$ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass
Success! Enabled userpass auth method at: userpass/
$ curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: root" -d '{"password":{"asdf":"my-sensitive-value"}}' "http://localhost:8300/v1/auth/userpass/users/adsf"
{"errors":["error converting input for field \"password\": '' expected type 'string', got unconvertible type 'map[string]interface {}', value: 'map[asdf:my-sensitive-value]'"]}

Impact

This is an information disclosure bug with little mitigation. See https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717 for a previous version. That version was fixed, but this is in the second part of that error message (starting at '' expected a map, got 'string' -- when the field type is string and a map is provided, we see the above information leak -- the previous example had a map type field with a string value provided).

This was rated 4.5 Medium by HashiCorp in the past iteration.

Use of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields.

Summary

Use of this library in a security-critical context may result in leaking sensitive information, if used to process sensitive fields.

Details

OpenBao (and presumably HashiCorp Vault) have surfaced error messages from mapstructure as follows:

https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L43-L50

			_, _, err := d.getPrimitive(field, schema)
			if err != nil {
				return fmt.Errorf("error converting input for field %q: %w", field, err)
			}

where this calls mapstructure.WeakDecode(...): https://github.com/openbao/openbao/blob/98c3a59c040efca724353ca46ca79bd5cdbab920/sdk/framework/field_data.go#L181-L193

func (d *FieldData) getPrimitive(k string, schema *FieldSchema) (interface{}, bool, error) {
	raw, ok := d.Raw[k]
	if !ok {
		return nil, false, nil
	}

	switch t := schema.Type; t {
	case TypeBool:
		var result bool
		if err := mapstructure.WeakDecode(raw, &result); err != nil {
			return nil, false, err
		}
		return result, true, nil

Notably, WeakDecode(...) eventually calls one of the decode helpers, which surfaces the original value via strconv helpers:

https://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L720-L727

https://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/mapstructure.go#L791-L798

https://github.com/go-viper/mapstructure/blob/8c61ec1924fcfa522f9fc6b4618c672db61d1a38/decode_hooks.go#L180

& more. These are different code paths than are fixed in the previous iteration at GHSA-fv92-fjc5-jj9h.

PoC

To reproduce with OpenBao:

$ podman run --pull=always -p 8300:8300 openbao/openbao:latest server -dev -dev-root-token-id=root -dev-listen-address=0.0.0.0:8300

and in a new tab:

$ BAO_TOKEN=root BAO_ADDR=http://localhost:8300 bao auth enable userpass
Success! Enabled userpass auth method at: userpass/
$ curl -X PUT -H "X-Vault-Request: true" -H "X-Vault-Token: root" -d '{"ttl":"asdf"}' "http://localhost:8200/v1/auth/userpass/users/asdf"

--> server logs:

2025-06-25T21:32:25.101-0500 [ERROR] core: failed to run existence check: error="error converting input for field \"ttl\": time: invalid duration \"asdf\""

Impact

This is an information disclosure bug with little mitigation. See https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717 for a previous version. That version was fixed, but this is in the second part of that error message (starting at '' expected a map, got 'string' -- when the field type is string and a map is provided, we see the above information leak -- the previous example had a map type field with a string value provided).

This was rated 4.5 Medium by HashiCorp in the past iteration.

overview:
this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer without a size cap.

this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection).

severity

HIGH

not claiming: this is a remote dos against every default deployment.
claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.

callsite (pinned):

• exporters/otlp/otlptrace/otlptracehttp/client.go:199
• exporters/otlp/otlptrace/otlptracehttp/client.go:230
• exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170
• exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201
• exporters/otlp/otlplog/otlploghttp/client.go:190
• exporters/otlp/otlplog/otlploghttp/client.go:221

permalinks (pinned):

• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221

root cause:
each exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error paths, with no upper bound.

impact:
a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).

affected component:

• go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp
• go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp
• go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp

repro (local-only):

unzip poc.zip -d poc
cd poc
make canonical resp_bytes=33554432 chunk_delay_ms=0

expected output contains:

[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512

control (same env, patched target):

unzip poc.zip -d poc
cd poc
make control resp_bytes=33554432 chunk_delay_ms=0

expected control output contains:

[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232

attachments: poc.zip (attached)

PR_DESCRIPTION.md

attack_scenario.md

poc.zip

Fixed in: open-telemetry/opentelemetry-go#8108

overview:
this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer without a size cap.

this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection).

severity

HIGH

not claiming: this is a remote dos against every default deployment.
claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.

callsite (pinned):

• exporters/otlp/otlptrace/otlptracehttp/client.go:199
• exporters/otlp/otlptrace/otlptracehttp/client.go:230
• exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170
• exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201
• exporters/otlp/otlplog/otlploghttp/client.go:190
• exporters/otlp/otlplog/otlploghttp/client.go:221

permalinks (pinned):

• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190
• https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221

root cause:
each exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error paths, with no upper bound.

impact:
a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).

affected component:

• go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp
• go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp
• go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp

repro (local-only):

unzip poc.zip -d poc
cd poc
make canonical resp_bytes=33554432 chunk_delay_ms=0

expected output contains:

[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512

control (same env, patched target):

unzip poc.zip -d poc
cd poc
make control resp_bytes=33554432 chunk_delay_ms=0

expected control output contains:

[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232

attachments: poc.zip (attached)

PR_DESCRIPTION.md

attack_scenario.md

poc.zip

Fixed in: open-telemetry/opentelemetry-go#8108

Impact

The compose-go library component in versions v2.10-v2.4.0 allows an authorized user who sends malicious YAML payloads to cause the compose-go to consume excessive amount of Memory and CPU cycles while parsing YAML, such as used by Docker Compose from versions v2.27.0 to v2.29.7 included

Patches

compose-go v2.24.1 fixed the issue

Workarounds

There isn't any known workaround.

References

• [BUG] "docker-compose config" consumes huge amounts of memory with broken config docker/compose#12235

• fix(reset): Add cycle detector in reset.go compose-spec/compose-go#703

• refs issue:11706 Resolving the Alias value of Alias type node compose-spec/compose-go#618

• docker/compose@d239f0f#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6R10

Impact

Some cache backends allow configuring their credentials by setting secrets directly as attribute values in cache-to/cache-from configuration. If this was done by the user, these secure values could be captured together with OpenTelemetry trace as part of the arguments and flags for the traced CLI command. Passing tokens to Github cache backend via environment variables or using registry authentication is not affected.

If you passed a token value like this and use a custom OpenTelemetry collector for computing traces you should make sure that your traces are kept secure. OpenTelemetry traces are also saved in BuildKit daemon's history records.

Patches

Issue has been fixed in Buildx v0.21.3 or newer.

Workarounds

Avoid passing cache backend credentials with CLI arguments. Make sure access to traces and BuildKit history records is kept secure.